Re: os/wars - a compilation - was Re: SoNoboby knows by John Payson .

> > When you say cooperative multitasking, are you > > meaning MT where the code moves between any and > > all possible combinations of output states, waiting > > and testing at each one for conditions that say to > > go to a new output state and wait again? > Cooperative multitasking is multitasking where a context switch > occurs only when the current task or thread decides it is prepared > to relinquish the CPU. This is usually done by calling an OS > function, e.g. Yield(), which will either return immediately if > no other task is ready to run, or perform a context switch if there > is another task ready. Unfortunately, no PIC (not even the 17Cxx) can at present handle the general case of cooperative multi-tasking, where either/any process may execute a yield() from within nested procedures. The normal method for handling such task switching is to split the stack area into two or more pieces; on the 8x51, a task switch (assuming two tasks) would then be performed as: Yield: mov a,other_sp xch a,sp mov other_sp,a ret Calling Yield() will place the address following the call onto the stack, save the stack pointer and point it to the other stack, and then work on the other task. When that task calls Yield() the stack pointer will be restored with its old value, so RETurning will resume execution of the former task. Simple and very efficient. The best a PIC can do is have one task with arbitrary procedure nesting (up to the total stack limit) and have the other task(s) only yield at the "top" level [not within a routine]. For a two-way task manager, I think the following is probably the best approach (assuming the secondary task fits into 256 bytes): [general] There needs to be a byte variable called "Task2PC", and PCLATH should 'always' [any time there's a task switch] be pointed at the page containing task two. [for task 1] Yield should be a macro that reads as follows: call DoYield movwf Task2PC The DoYield label should point to the code: movf Task2PC,w movwf PC [for task 2] Yield2 takes an argument, which is an address to go to once task 1 yields again. The Yield2 macro [if you want to use a macro] is simply: retlw [address] [example] Task 1 is a general purpose who-knows what. Task 2 is a serial-port receive routine. For this particular application, assume the DoYield "routine" contains code to wait until the end of the current 1/3-bit-time clock. Task2 might then look like the following [written to maximize speed]: SerIdle: btfss PORTB,0 retlw SerIdle retlw SerGotStart1 SerGotStart1: btfss PORTB,0 retlw SerIdle retlw SerGotStart2 SerGotStart2: retlw SerGotStart3 SerGotStart3: clr DataIn retlw SerGetBit0a SerGetBit0a: btfsc PORTB,0 bsf DataIn,0 retlw SerGetBit0b SerGetBit0b: retlw SerGetBit0c SerGetBit0c: retlw SerGetBit1a SerGetBit1a: btfsc PORTB,0 bsf DataIn,1 retlw SerGetBit1b SerGetBit1b: retlw SerGetBit1c SerGetBit1c: retlw SerGetBit2a ... [I think the overall code size would end up being around 50-60 instructions for the receive routine. Using a loop would save code space, but would make the logic more complex.] Pseudo-cooperative multitasking like the above can be very useful, and can work quite effectively on a PIC (the total time to switch to and from the second task is eight cycles). Unfortunately, for applications where both tasks are complex, the requirement that the second task always be at top-level whenever yielding control can make clear and efficient coding difficult. Such jobs are perhaps better suited to other processors (alas) such as the 8x51 or 68HCxx. For most tasks, however, the PIC is a wonderful little chip.